Date: Sat, 2 Jul 94 04:30:01 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #136 To: tcp-group-digest TCP-Group Digest Sat, 2 Jul 94 Volume 94 : Issue 136 Today's Topics: NetROM over Ethernet? (Yuchhh...) NOS and the PC Stinkin PBBS (3 msgs) Why not a solid PBBS program? Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Fri Jul 01 11:24 EDT 1994 From: "Ackermann, John" Subject: NetROM over Ethernet? (Yuchhh...) To: tcp-group We're trying to figure out the most expeditious way to build a fairly large switch (2 64kb full duplex, 2 19.2kb half duplex, 3 9600, 1 1200 ports) and it looks like no matter what we do we'll need two boxes to support all the I/O. One possibility is two NOS boxes. Using ethernet to interconnect them seems like a reasonable thing to do. Can we attach netrom directly to an ethernet interface, or do we need to go through the axip stuff to do it? Thanks... John AG9V jra@lawdept.daytonOH.ncr.com ------------------------------ Date: Fri, 1 Jul 1994 18:36:33 -0700 From: Phil Karn Subject: NOS and the PC To: agodwin@acorn.co.uk I agree that DMA on the PC is an abomination that is best avoided wherever possible. Not only is that particular implementation especially bad, but much of the original economic and performance rationale for DMA has also gone away as the technology has developed. Fast CPUs, caches and cheap RAM are the most relevant developments. Much of the original motivation for DMA was economic. When memory was expensive, you didn't want to dedicate it to buffering a device that didn't get used all that often. You wanted to keep it general purpose. DMA is basically a main memory multiporting scheme; if you don't need a chunk of memory for a DMA buffer, you can use it to hold a program or data. The original idea behind DMA was to avoid the interrupt load and latency that would otherwise occur with high speed I/O to and from devices with little internal buffering (remember, memory was expensive). By transparently stealing memory cycles from the processor, I/O could occur without involving the CPU in a lot of busy waiting until the entire transfer was complete. The CPU could execute other, unrelated tasks while the transfer continued. But now that memory is cheap, you can move the "DMA buffer" to the device itself; it's okay if it isn't used all that often. And this buffer can be accessed by the CPU at its own speed; there's no need for busy waits between transfers (ignoring wait states, etc). There are other reasons to avoid DMA, even when it's reasonably well designed. The performance bottleneck in almost every modern workstation and high performance (e.g., 486-class) PC is main memory. That's why 486 processors have caches - so they can run faster than main memory. But when a DMA device asynchronously accesses main memory, the cache controller has to take great pains to ensure cache/memory consistency. At a minimum, this means operating in a write-through mode, giving up any cache gains on write operations. And whenever a DMA device writes main memory, the cache controller must ensure that any stale data in the cache is invalidated. Depending on the cache design, this can significantly degrade performance. Just to comment on one point you made: DMA : The PC's DMA controller is used to perform the transfer. The DMA controller performs a sequence of memory writes (using internal counters), but simultaneously drives signals to the card which act rather like an I/O read and provide a single byte in each operation. This halves the number of bus cycles used for the transfer, and requires no overhead from the CPU. Actually, for modern CPUs I believe the number of ISA bus cycles is the same. In the CPU-driven transfer the data flows between CPU and memory over a separate and much faster memory bus, so the ISA bus remains the bottleneck. In fact, if you look at the end result the DMA transfer often ends up consuming many more total bus cycles than the CPU-driven approach because of DMA buffer placement restrictions that often require the CPU to copy data between the DMA buffer and where it really wanted it to go in the first place. This is a problem particularly with 486s that have more than the 16 meg of memory that the ISA bus can address. If you happen to have a program buffer above the 16 meg boundary, you have to first copy it into a "bounce buffer" below 16 meg before you can DMA it (this is common practice with DMA disk controllers like the Adaptec 1542B, popular on UNIX systems). And even when you have less than 16 meg, bounce buffers are required if your original program buffer happens to straddle a 64K physical boundary. As for the two approaches (memory mapped and I/O mapped) used on modern PC ethernet cards, they are probably equivalent in performance because they are both limited by the ISA bus rate. However, the I/O mapped approach is highly preferable, at least in real-mode systems, because memory mapping can take up a good-sized chunk of upper address space. Phil ------------------------------ Date: Fri, 1 Jul 1994 08:08:35 -0500 (CDT) From: ssampson@sabea-oc.af.mil (Steve Sampson) Subject: Stinkin PBBS To: tcp-group@ucsd.edu bbattles@arrl.org writes about what dgregor@bronze.coil.com writes: >> I've been thinking of something like this. If everyone could get together >> and write a good Amateur Radio PBBS program for Linux > why isn't there a good, solid, NOS-based PBBS package available for hams who > run DOS, Windows or OS/2 machines? Gary L. Grebus writes: > "Stamp out the PBBS in our lifetime." Gary speaks pretty much the opinion of most people that have been around packet radio for any length of time. If you really want to bore someone to death, have them buy a TNC and log into a PBBS for 10 days; then call the coroners office for a pickup. It's not something that gets better with age. Just like the bulletin board in the lobby of schools and offices, nobody ever reads it, but a lot of people stick things on it. Probably the only intelligent thing I've read on the subject of transfering information has to do with broadcast protocols. For example, it seems criminal that a PBBS would hand deliver copies to a circle of machines on the same frequency (e.g., a satellite, or a town PBBS) when it could just broadcast the information while the others listened. The other really interesting article is "The HUB 5/29 IP Routing Experiment" in the 12th ARRL Digital Conference. Read this, and then decide whether your still interested in a boring PBBS. Paul Overton and Ian Wade discuss a really nice routing scheme (only a mobile user would complain I suspect - but TCP/IP isn't ready for mobile/portable anyway) and then goes on to explain their modifications to NNTP that takes advantage of this. We've seen several automated IP routing schemes proposed, but the truth is that Ham networks don't need them. If you have more than 3 entries in your routing table, you should read this article. I'd like to read more about this system and maybe see a distribution for others to duplicate. Basically I see no advantage of prolonging the PBBS given an operating network. The lack of a network is the reason the PBBS exists today. I think if towns or communities developed along the lines of the HUB 5/29 article it would make for a simple (easily duplicated) network scheme that could transport more substantial mail or news articles. I know this will never happen in Oklahoma, because there is no organization, but other communities should look into this network and abandon the stupid PBBS, Rose, and Netrom. -- Steve ------------------------------ Date: Fri, 01 Jul 94 15:55:24 From: kz1f@RELAY.HDN.LEGENT.COM Subject: Stinkin PBBS To: tcp-group@UCSD.EDU > Gary speaks pretty much the opinion of most people that have been around > packet radio for any length of time. If you really want to bore someone > to death, have them buy a TNC and log into a PBBS for 10 days; then call > the coroners office for a pickup. It's not something that gets better > with age. I couldn't agree more. However I think the real problem is the bulk of the PBBS users are running DOS (or maybe even Windoze) and use a terminal emulator or (terminal.exe) to log into their favorite PBBS. The machines are probably 286's and the memory is 640k. To answer Brian's question, the folks writting the 'really slick new" software aren't running 286's with 640k and given its such an labor of love to write this stuff they generally write it with the understanding that they too will use it. If I am reading the sentiment right one won't find any more DOS based xNOS's. There will be char based Lunix, or graphically based OS/2 or maybe even Windoze based versions of tcp/ip suites that may not even support AX.25 mailboxes nor netrom....I know mine won't. Walt ------------------------------ Date: Fri, 01 Jul 1994 17:39:11 -0400 From: "Brandon S. Allbery" Subject: Stinkin PBBS To: kz1f@RELAY.HDN.LEGENT.COM In your message of Fri, 01 Jul 1994 15:55:24, you write: +--------------- | too will use it. If I am reading the sentiment right one won't find any more | DOS based xNOS's. There will be char based Lunix, or graphically based OS/2 +------------->8 You won't be finding (m)any more DOS-based *servers*. Clients can be darned near anything; it's the SMTP/PBBS/convers/NNTP/etc. server hosts that are crashing (sometimes literally) into the 640K limit all too regularly. ++Brandon -- Brandon S. Allbery kf8nh@44.70.4.88 bsa@kf8nh.wariat.org Friends don't let friends load Windows NT (tnx Sun) A Linux iBCS2 developer The Witness (the Universe's biggest practical joker) is at it again... who else would pit the U.S. soccer team against Brazil on the Fourth of July?! ------------------------------ Date: Fri, 1 Jul 1994 18:56:55 -0700 From: Phil Karn Subject: Why not a solid PBBS program? To: bbattles@arrl.org > Perhaps it would take a commercial venture to do it right. Would a PBBS >SysOp, who's spent maybe $1000-$2000 (or more) on radios, TNCs, antennas, >PCs, etc, also shell out maybe $50-$100 or so for GOOD software that beats >the heck out of the standard freebie AX.25 PBBS packages or the bazillion >semi-complete NOSs floating around? Why do we have to have PBBSes at all, especially if we're using TCP/IP? Why do hams have to keep reinventing the wheel, especially ones that aren't quite round? What's wrong with just using all the mail and news software that the rest of the Internet uses that seems to work fine for them? Why do hams always have to be different? Phil ------------------------------ End of TCP-Group Digest V94 #136 ******************************